Databases are widely used for facilitating data organization and access. As electronic commerce continues to grow, so too does the need for robust databases that are always on and always available to prospective users. For example, many Internet-based merchants rely on database systems to provide product information and track customer orders, inventory, and other important information. Downtime for such databases means lost sales and, thus, lost revenues for the merchants.
Databases are also used for more than just product sales. Communications systems, such as electronic mail (email systems), that route data across the Internet also rely on databases to store user account information to determine the appropriate parameters for sending data to a given users. For example, an email relay system may include a mail user agent (MUA), which is an application that uses a technique called polling to relay messages from the mail server to the mail program at a user's computer or mobile wireless communications device. A MUA is a program running either on a user's personal computing device (mobile or stationary), or on a shared email relay server that checks for new mail on behalf of a multitude of such users. More particularly, polling is the retrieval of incoming messages from other users at the mail server and delivery of these messages to the user's mailbox. Particularly in the case of an email relay server, it is important that the databases which maintain email data (e.g., account information, lists of previously received emails, etc.) for respective users be constantly available so that email forwarding can continue without interruption.
Various approaches are sometimes used to help keep database downtime to a minimum. In an article by Mullins entitled “Dealing with Downtime,” from Database Trends and Applications, January 2002, the author notes that database outages take one of two forms, namely planned or unplanned. Planned outages are typically for the purposes of database maintenance, upgrades, etc., while unplanned outages result from causes such as disasters, hardware failures, and operating system crashes. Mullins notes that planned outages typically account for a greater percentage of database downtime, and thus describes potential proactive techniques to reduce the time that a database has to be offline for planned outages.
While such techniques may help mitigate planned database outages, the typical approach for dealing with unplanned outages is more reactive than proactive. That is, database administrators often end up waiting until an unexpected database problem occurs and then attempt to analyze and repair the problem on the fly. However, this requires that the appropriate personnel be available when such events occur, which may not always immediately be the case. Even when it is, it may take a significant amount of time to isolate the cause of such a problem so that it can be corrected. As such, it may be desirable in certain database applications to have a more proactive approach to mitigating the effects of unexpected database downtime.